Repository navigation
Preserve the declared width of short raw and text fields - #60
rupayon123 wants to merge 2 commits into
Conversation
|
so C implementation still has the bug? please fix it as well in that case |
|
The C backend now zero-pads short and empty raw/text payloads too. It writes the available bytes, pads the remaining field bytes, and keeps the following field at the correct offset. The documented C restriction to byte-multiple raw/text field widths is unchanged. I rebuilt and installed the CPython 3.13 wheel. The full suite passes (56 tests and 377 subtests), as does the unittest command. The new cases cover direct, compiled, dictionary and pack-into calls, including non-byte-aligned offsets and preservation of the surrounding destination bits. An independent wire-format check also passes all 12,320 observations on the installed C extension. |
|
remove new test file. make new tests easier to read an understand. less looping, fewer conditions. straight forward easy to read test code |
Short raw and text fields in the Python implementation can produce fewer bits than their declared width. Round the missing byte count upward before the existing truncation and bit-order handling, so following fields keep their declared offset.
Following review, the native C backend now also zero-pads short or empty raw/text payloads at its supported byte-multiple widths. It uses the existing byte writers to preserve adjacent fields and untouched pack-into bits. The documented C restriction to byte-multiple field widths and existing type checks remain unchanged.
Native CPython 3.13.14 / macOS arm64 validation:
Existing raw bytearray ownership semantics are unchanged. Other hosted runtimes/platforms remain separate from these local checks.